Migrating an app, especially one implemented by someone who should probably do other things for a living, isn’t always an easy business. Nothing overly challenging, nothing technically impossible, but there are still things one should be aware of from the start to avoid excessive hassle, spare the client some of the costs and keep a good reputation. We’ve recently excelled across the board while implementing a project for a Scandinavian client and we’d like to share some of the insights we’ve gained with you. Perhaps, you’ll find something useful for your future migration endeavors.
Our client, a Swedish innovation agency that caters to several household names that you’ve, normally, been aware of since you were a kid, approached us to improve the performance of one of their mobile apps. The app is intended to conduct advanced employee surveys on the fly. It is part of a larger system that also included a Web-based application.
While it was well developed, the client’s app still had a number of flaws and it was definitely antiquated technology-wise. The need to move the software to a newer technology stack was obvious. The client being in agreement and eager to have things put right, we settled into to the task.
The project’s scope comprised three main tasks: migrating the functionality responsible for the app's interaction with the Web-based back-end, updating and optimizing it's GUI and, finally, improving the testability of the software.
So, let’s now look at the challenges we’ve encountered and ways in which we’ve met them to make the project a success.
1. Large Amount of Code to Migrate: Use React Programming
There were loads of code to deal with. We knew at once this amount of code would overload the system very significantly and slow down the migration process quite a bit. In addition, the number of modifications that would have had to be made across this data would have been very large. In order to avoid this, we decided to bring RX Android into play.
As the technology allows using threads to create queries that retrieve only the data that is required at the moment, we’ve managed to avoid both of the above issues. The code migration process has been smooth and relatively expeditious.
Summing up, the pros of the approach we opted for are as follows:
- You can make the transition to the new version gradual and do so without affecting the app’s initial logic.
- You can make the application thread-safe and eliminate the need for using the Main Thread for the performance of time- and resource-consuming operations.
- You can make the app’s architecture a great deal more flexible by using the Observable - Subscriber combination from RxAndroid. This will expedite the development process and make the app’s logic more coherent.
Currently, we are planning to move the rest of the app’s business logic to Reactive with a goal of being able to perform complex operations more promptly and with greater ease.
2. Increasing the App’s Responsiveness: Use Custom Android
The client’s app didn’t sport a GUI you could refer to as extremely user-friendly or optimal from the point of view of UX. Moreover, the app was not responsive enough and we were faced with the need to enhance it's responsiveness very considerably.
While dealing with the latter task, we noticed that the external library utilized by the app, accounted for some 50% of the app’s size.
We decided to migrate all of the application’s views from external to custom Android apps. This has proven to be a great decision. Using custom Android has allowed us to vastly improve the responsiveness of the client’s app. Most of the libraries we got rid of had been used by the app for no more than 10-15%, but had to be downloaded in their entirety. This is no longer a problem with Android custom views.
3. Use Unit Testing While Migrating: Longer, But Highly Efficient
Moving an app to a new version is bound to make a bunch of bugs surface. Willy-nilly, you’ll have to deal with them in midstream. More so, we had to maintain both versions of the app and ensure compatibility between them. This increased the odds of us making a critical mistake, either in the old version or in the new one, that would then prove to be extremely hard to correct.
We decided that it would be prudent to spend more time on QA than hunt for well-hidden bugs later. We divided the app's architecture into modules, composed a set of tests and used Mockito to test the app in a modular fashion.
Just as expected by us, we had spent much less time on composing the tests and performance of the testing than we would have had on fixing a dozen moderately dangerous bugs.
© 2017, Vilmate LLC
